Networked systems are becoming both increasingly prevalent and increasingly complex. Frequently, they encompass a large number of diverse modules; accordingly, the potential for incompatibility issues to arise grows ever greater. These problems can often to lead to system failures or other forms of abnormal operation. They are often difficult to diagnose when they occur and even more difficult to predict prior to deployment.
In the field of computing, there are an increasing number of computing modules (for example distributed services, workstations, file/database servers, storage systems, printers, and the like) being connected with each other through a network. Such modules may be software components such as web services or software libraries, or hardware components such as network interfaces or storage controllers. An example of the former can be found in a travel reservation service, which may comprise a front-end module that provides a uniform presentation to its users and back-end service modules that are in charge of flight reservation, hotel reservation, rental car reservation, and checking for travel policies applicable to the user. An example of the latter can be found in a networked storage system, where a group of servers share storage devices via a high-speed switching fabric. Often, software modules and hardware modules have interoperability rules, for example a certain version of software modules will only work with a set of hardware modules only.
To enable interoperation between computing modules, standardized protocols for networking, such as Simple Object Access Protocol (SOAP), transfer control protocol/Internet protocol (TCP/IP), Fiber Channel, and small computer system interface (SCSI), have been proposed in web services, internet, storage area network, and device interconnections, respectively. While such standards help interoperability among peer computing modules, they are not designed to address interoperability among computing modules that are not peers of each other. Furthermore, the interoperation between any two computing modules is not always warranted. For example, certain technical areas, such as networked storage systems, have a relatively short history and are rapidly evolving, thus resulting in inconsistent implementation of standards where standards exist at all. As a result, it may be important to ensure that all devices in a networked system will work together when developing with a new configuration or changing an existing configuration by adding, removing, or reconfiguring modules.
To illustrate the problem, we take an example from the management of storage area networks (SAN). Currently, each vendor publishes lengthy documents which contain the interoperability rules for each storage device and each SAN switch product they sell. Such a document typically lists all the devices that have been tested and are known to work with the corresponding device. Human administrators who manage networked storage systems use these documents as reference manuals for designing and troubleshooting. In such documents, interoperability rules may be represented in plain English as well as in a table format. These restrictions may include the version of firmware that is recommended for particular server/storage combination, and such recommendations as “both tape and disk should not be attached to the same host bus adapter (HBA),” and the like. These interoperability rules arise despite various standards, for example Internet Small Computer System Interface (iSCSI), Network File System (NFS), and Common Internet File System (CIFS) for connecting SAN devices.
At present, a majority of networked storage systems are designed by SAN experts or technical consultants. When these human experts design a storage system, they must consider existing devices (such as hosts and servers if there are any) and determine the types and the number of storage systems and how to configure those storage systems using SAN switches. In this process, the human expert will have to refer to the interoperability documents to identify candidate devices and decide which devices are appropriate. In many practical scenarios, the experts may decide to buy all systems from a single vendor to eliminate the possibility of configuration problems. However, this certainly limits the available choices for the user and the user will tied to a particular manufacturer in the future. Overall, this manual process for SAN design will likely result in suboptimal and expensive design. It is also possible, that the expert may in fact misinterpret the information in the interoperability document and misconfigure the system, which will later take a lot of time to fix, and result in lost or below par services.
There are tools that to help human SAN designers take the information on host devices, storage devices, and SAN switches as input from the user and display a resulting configuration. Although these software tools are useful and some of them provide primitive solutions to device interoperation checking, they can check the relation of only a fixed set of devices using a fixed set of configuration rules, which have been provided by the software vendor.
It would thus be desirable to overcome the limitations in previous approaches.